WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 




PCX 

.TERNATIONAL APPUCATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



international Patent Classification ^ : 
H04Q 3/545, H04M 3/36, H04L 12/26 



Al 



(11) Internatfonal Publication Number: 
(43) International Publication Date; 



WO 99/34623 

8 July 1999 (08.07.99) 



(21) International Application Number: PCrr/n98/00972 

(22) International Filing Date: 1 1 December 1998 (1 L12.98) 



(30) Priority Data: 
974533 



16 December 1997 (16.12.97) FI 



(71) Applicant {for all designated States except US): NOKIA 

TELECX3MMUNICATIONS OY [FI/FI]; Keilalahdentie 4, 
FIN-02150 Espoo (FI). 

(72) Inventors; and 

(75) Inventors/Applicants (for US only): SAARI, Jarmo [FI/FI]; 
Auvilankuja 3 C 15, FIN-40740 Jyvaskyia (FI}. TASK- 
INEN. Timo [FI/FIJ; Vclcaratie 4, FIN-44120 Afinelcoski 
(FI). 

(74) Agent: PATENT AGENCY COMPATENT LTD.; Teollisu- 
uskatu 33, P.O. Box 156, FIN-00511 Helsinki (FI). 



(81) Designated States: AL. AM, AT, AU, AZ, BA, BB, BG, BR. 
BY, CA. CH. CN. CU, CZ, DE, DK. EE. ES, H, GB, GD, 
GE, OH. GM, HR. HU, ID. IL, IN, IS. JP. KE, KG. KP, 
KR, KZ, LC, LK. LR. LS. LT. LU. LV. MD. MG, MK. 
MN, MW. MX. NO, NZ, PL. FT. RO, RU, SD. SE. SG, 
SI. SK. SL. TJ, TM, TR. TT. UA. UG. US. UZ. VN. YU. 
ZW. ARIPO patent (GH, GM, KE. LS, MW, SD. SZ. UG. 
ZW), Eurasian patent (AM, AZ. BY, KG. KZ, MD, RU. TJ. 
TM). European patent (AT, BE, CH. CY. DE. DK, ES, FI. 
FR, GB, GR, IE, IT. LU, MC, NL, FT, SE), OAPI patent 
(BF, BJ, CF. CG, CI. CM, GA, GN. GW. ML, MR, NE, 
SN, TD, TG). 



Published 

With international search report. 

Before the expircaion of the time limit for amending the 
claims and to be republished in the event of the recent of 

amendments. 

In English translation (filed in Finnish). 



(54) Title: EVENT PRE-PROCESSING FOR COMPOSING A REPORT 



21 

u 



Report 
Request 
Service 
Block 

RSB 



23 



ELEMENTARY 
EVENT 



C0MDIT10M 



REQUESTER 



COUNTER SERVICE 
BLOCKS 
CSB 




(57) Abstract 

It is a problem with telecommunication equipment, such as a telephone exchange, that the countere produce so much information 
that the processes, such as statistic, traffic management and charging, do not have the time to process them. The system accordmg to 
the invention includes two main blocks: the first main block is formed by one or more report request service bkxte 21) and second 
main block (22) is fomied by one or more counter service blocks, each of which monitors one or more counters (cl,.../;n). The report 
reouest service block relays a start-up message (23) to those counter service blocks (e.g. 24) from which it needs counter infonnatoon. The 
3woron whiTh £ i^unter information is desired axe stated in the message. TTie condition may be exceeding/falUng short ofagiven 
threshold value or the condition may be a timetable, e.g. a time slot, in accordance with which the county value .s to be 'tated. Wto^the 
given condition is fulfilled, the requested counter service blocks will read the counter values, locate ttiem in a brief message, each value in 
its own message, and send the message to the report request service block (21). 
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Event pre-processing for composing a report 
Field of the invention 

This invention generally concerns a method for reading and pre- 
processing a huge quantity of individual elementary events which are to be 
monitored in such a way that only desired events or sets of events are ex- 
tracted for further processing. 

Technical background 

There are applications in numerous telecommunication facilities 
where huge quantities of data are collected. Numerous counters, measuring 
events producing measurement results and events to be monitored are used 
in the collection. Counters are typically used to measure the duration of an 
event. Sometimes the duration Is without significance, so that only such 
information Is sufficient which tells whether an event has occurred or not. An 
example of such Is some magnitude which must be monitored, such as tem- 
perature, voltage, current, number of events or any other such threshold 
value the exceeding or falling short of which is an event to be monitored. In 
some cases again information on the present value of the magnitude to be 
measured is needed at the moment of inquiry. In many cases, the readings 
of counters, events and measurements are dependent on one another, but 
this is by no means always the case. 

Hereinafter, the name elementary event will be used for the sake 
of brevity to mean both a counter operation, a measurement and any individ- 
ual event. 

The telephone exchange is a typical telecommunication facility 
which produces an enormous quantity of data. It may contain even thou- 
sands of counters, some of which are working all the time, while some work 
at times, e.g. for periods of 15 minutes, and some will work when triggered 
off by a threshold value. In addition, it includes many events which must be 
monitored and the implementation of which will start some function. All these 
elementary events represent an enormous data flow which is constantly 
changing. From this information flow the operator selects the data he needs 
for further processing. The operator tells the manufacturer of the exchange 
what information he needs and in what form it should be. The manufacturer 
then makes such arrangements in the software of the exchange which will 
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filter out the desired events from the elementary events and will locate them 
In so-called reports, which are used In the exchange or which are sent out 
from the exchange e.g. to network management. Typical reports are the 
accounting data needed to carry out charging, various statistical reports, 
6 reports needed in traffic control etc. 

A CDR report is presented as an example of a report. For each 
call which is made the Local Exchange LE performs call detailed charging 
and forms a Call Detail Recording CDR. The record contains for one call ail 
the data needed to charge for the call as well as the desired quantity of other 

10 data relating to the call. Such data is e.g. the A number, the B number, the 
duration of the call and the moment when the call begins and ends respec- 
tively. The formed CDRs are sent to billing centre BC for further processing. 
In order to generate the call detail recording, the operator must establish 
some basis to fomn it. The ground for formation may be e.g. call detailed data 

15 collection for all calls of the subscriber or a formation based on the type of 
call, that is, whether the call is an ordinary call, a facility call such as call 
fonvarding, a call free of charge etc. The call detailed data collection thus 
produces enormously big data blocks which contain even millions of reconds 
and which must be stored In the mass memory of the charging system. The 

20 counters, besides fomiing the charging record, also find out whether the call 
was successful or not, and the result is used for statistical purposes. For 
traffic management such reports are produced which show the number of 
successful and failed calls as a function of time. 

Figure 1 illustrates the practice mentioned above. The elementary 

25 events arriving from various sources are combined In the counting process to 
fomi raw data blocks, which are then moved on to charging, statistics- 
keeping etc. for further processing. The processor may need only a fraction 
of information from the raw data block, but in spite of this, all elementary 
events must be read and the processor must receive the whole data block. 

30 't is a problem with the present arrangements that in a telecom- 

munication facility, such as a telephone exchange, the quantity of arriving 
data is so big that the statistic, traffic management and charging systems do 
not have the time for processing the infonnation, at least not in real time, so 
their processing capacity has become a bottleneck. This may be harmful 

35 both to the operator and to the customer. As an example such a situation 
may be mentioned where some such necessary piece of charging data is 
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lacking in the subscriber's call set-up which the traffic management has not 
had the time to produce due to the data overflow constantly arriving there. 
When this necessary piece of data is missing, the call can not be connected 
at all. 

5 it is an objective of this invention to eliminate the problems occur- 

ring in the present-day arrangements. 

The objective is achieved with the system defined in the inde- 
pendent claims. 

1 0 Brief summary of the invention 

The system according to the invention includes two main blocks: 
the first main block is comprised of one or more report request service blocks 
and the second main block is comprised of one or more counter service 
blocks, wherein each counter service block monitors one or more elementary 

15 events, such as a counter. The system at a minimum includes at least one 
report request service block and one counter service block. 

The task of each report request service block is to form a report. It 
may receive a request from outside of the system, or some factor inside the 
system may trigger off a request. From the request it concludes what infor- 

20 mation on what elementary events is needed in the report. Thereafter infor- 
mation on the required elementary event is relayed as a start-up request to 
those counter service blocks, which are monitoring the said elementary 
events. In response to the request, these counter service blocks state the 
values of the said elementary events to the report request service block, 

25 which will use the received data for forming a report. 

The elementary events, that is, counters, meters and events, work 
in the ordinary way producing information as a constant flow. The elementary 
events can be grouped In such a way that one counter service block may 
monitor several elementary events. Each counter service block reads the 

30 values of the connected elementary events in accordance with a pre- 
determined instruction. Thus, the counter service block is a kind of controller. 

The predetermined instruction is given by the report request serv- 
ice block. In the instruction those conditions are given on which the value of 
each elementary event is desired. The condition may be exceeding/falling 

35 short of a given threshold value or the condition may be a timetable, e.g. a 
time slot, by which the value of the elementary event must be stated. When 
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the given condition is fulfilled, the requested counter service blocks will read 
the elementary event infomiation and will locate it in a brief message, each 
piece of information in its own message, and will send the message to the 
report request service block. 

Thus, the essential Idea of the Invention is to send on from the 
places of observation of elementary events that information only which is 
needed at each time and only when it Is needed. All other such information 
on elementary events which Is not needed at the time In question is not sent. 
The flow of information can thus be reduced considerably land the capacity of 
upper levels is prevented from becoming a bottleneck. 

The first embodiment is a static embodiment of the basic inventive 
idea. According to this, each counter service block and the related elemen- 
tary events form a predetermined permanent entity. The report request serv- 
ice block sends a request to those counter service blocks only on the moni- 
tored elementary events of which it needs infomiation. The static embodi- 
ment is simple and reliable in operation. 

Another embodiment is a dynamic embodiment of the basic In- 
ventive Idea. In this counter service blocks are formed as required in such a 
way that when a report request service block sends a request, such a 
counter service block Is created to implement the request, which includes 
exactly the elementary events mentioned in the request. The counter service 
block will live only for as long as is required. In order to Implement this em- 
bodiment, a special management programme must be fonned, the duty of 
which Is to manage the counter sen/ice blocks and whenever required to 
report to the report request service block what elementary events are avail- 
able. The dynamic embodiment is especially advantageous, because only 
the required counter service blocks exist and because the elementary 
events, that is, the counters, may be covered from the party needing the 
service. 

Brief description of the drawings 

The invention will be described in greater detail with the aid of the 
appended schematic drawings, in which 

Figure 1 shows the formation of raw data blocks; 
Figure 2 Illustrates the principle of the invention; 
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Figure 3 shows the contents of a reply message; 

Figure 4 shows the contents of a start-up message; 

Figure 5 is an example of a first embodiment; 

Figure 6 Illustrates the course of events; 

5 Figure 7 is an example of a second embodiment; and 

Figure 8 illustrates the course of events. 

Detailed description of the invention 

Figure 2 is a simplified view of the inventive principle. Report re- 
10 quest service block 21 RSB is a process which needs values of certain ele- 
mentary events. The RSB may need counter data for its own use, or it may 
receive from some outside process a request to supply a report of a certain 
Icind, which contains information on given counters. The elementary event is 
marked with the reference c1, c2, c3. .. cn. The elementary events may be 
15 counter values, measurement results or any other events. For the sake of 
clarity a counter will be used in the following text as an example of an ele- 
mentary event. 

When report request service block RSB needs information on 
certain counters, it forms message 23 and sends it to controllers, which will 

20 be called Counter Service Blocks 22, CSB hereinafter. Message 23 contains 
at least the necessary counter identifier, a condition and the Identifier of the 
process requesting the counter information. Since the requesting process 
may need the counter value either at once, later or at times, information 
about this is given in the "condition" field of the message. Information con- 

25 ceming tens of counters, even hundreds of counters, is relayed in the same 
message given to the counter service block. The message hereby includes 
the corresponding nurriber of frames, each one of which contains matters in 
accordance with message 23. 

Each counter service block monitors at least one elementary 

30 event c1, c2, c3, ..cN. In the example, counters c1, c2, c3 and c4 are com- 
bined in the same counter sen/ice block 24, whereas counter c5 and counter 
cn are combined each in its own counter service block. The elementary 
event connected to each counter service block functions independently of 
the block, that is, the counters count continuously, measurements are per- 

35 formed continuously etc. But when some counter service block receives such 
a message 23 report request service block 21 which in accordance with the 
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condition in the message requests immediate infonnation on the value of e.g. 
counter c5. this counter service block 25 will read the present value of the 
counter. Thereupon the counter service block forms a brief reply message in 
accordance with Figure 3. whereby the fields of the message are the 
counter's name, the counter's value and the time stamp. In this case shown 
as an example, the counter identifier (c5) is located In the name field, the 
read value is located in the value field and the time stamp is located In the 
last field, that is. that moment when the counter value was read. Formed 
reply message 31 is sent to that process of report request service block 21. 
which is mentioned in the mentioned "process" field of the start-up message: 
Figure 4 illustrates a possible start-up message. Its frames include 
several start-up messages 23 in accordance with Figure 2. It emerges from 
the first line (frame) that the statistics-keeping process wants to know when 
the value of counter c1 exceeds threshold value k1. The counter must be 
read at Inten/als of t1. It emerges from the second line that the statistics- 
keeping process wants the value of counter c2 at intervals of t2. If there is 
Infomiatlon in the "threshold" or "inten/al" field, this means that the counter 
service block must work according to a timetable without any separate addi- 
tional messages. On the last line of the message the threshold and interval 
fields are empty. The concerned counter service block hereby knows that the 
value of counter cn is wanted at once and only this time, ft should be noted 
that since the frame of the start-up message may be different from another 
only as regards the requesting process, the same counter sen/ice block may 
have to send reply message 31 containing the same infonnation to more 
than one place. 

In the case shown in Figure 2 there is only one counter service 
block 24 for the sake of clarity, to which several elementary events are con- 
nected which have to be monitored. Since e.g. a telephone exchange may 
contain thousands of counters, it is advantageous to arrange elementary 
events in groups, each of which is controlled by its own counter sen^ice block 
CSB. Thus at least just one elementary event may be connected to one 
counter service block or there may be hundreds of events. 

First embodiment of the invention 

In the arrangement according to the first embodiment of the in- 
vention, the elementary events belonging to the counter service block are 
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determined in advance. The counter sen/ice blocks exist always and the 
report request service block sends a request to those counter service blocks 
the counters of which it needs, and it also states a timetable in the request. 
In this sense the first embodiment may be called a static embodiment. 
5 Figure 5 shows a static embodiment which is an arrangement in 

accordance with Figure 2 adapted to a telephone exchange. Inside the dot- 
ted line 51 there are several report request service blocks which are different 
processes. The figure shows a traffic management process 511. astatistic 
process 512, charging process 513 and performance monitoring process 

10 514. Each process must form reports containing predetermined elementary 
events and must send further the reports it has formed. Thus, call charging 
process 513 collects elementary event data needed in call records, forms call 
detail records CDR of them and sends them to the operator's charging centre 
for further processing. The statistic process again needs a large set of pre- 

15 determined elementary events in order to create statistical reports from these 
which are sent further to another place for processing. The customer deter- 
mines the form of the reports, that is. what elementary events are needed for 
each report and what form the report shall have. The report form can be 
supplied to report request service blocks 51 by way of the MMI user interface 

20 of the exchange or it may be given by remote control through the network 
management. 

Each report request service block, that is, each process makes 
messages stating the required elementary events and the conditions, when 
these are required, to the reports which must be forrned by the processes. 
25 The message assemblies in accordance with Figure 4 are sent by the proc- 
esses to the couriter service blocks which are shown inside dotted line 52 in 
the figure. 

The counter service blocks assemble the elementary event data in 
accordance with the instructions given in the messages, locate them in the 
30 reply messages, Figure 3. and send reply messages 31 to the processes 
which have requested elementary event data. In the figure, the progress of 
reply messages is shown by the arrows starting from the counter service 
blocks and ending in the report request service blocks. 

The various steps are described with the aid of Figure 6. Some 
35 report request service block receives a request to form a report. The request 
may be for formation and sending back of e.g. a statistic report, which con- 
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tains e.g. failed and successful calls within a certain period of time, or a re- 
quest to form call detailed recordings, which contain only certain information 
relating to a call, or a request to form at certain intervals a traffic report which 
contains all calls within a certain period of time. The report may be sent in 
5 accordance with some timetable, whereby the request is automatic, or the 
request may be sent only when some report is desired. 

The report request service block determines what elementary 
event data is required in the report and how it must be read. For some 
events the present value is sufficient, whereas for other events it may be 

10 necessary to collect elementary event values over a certain period of time. 
Some events are compared with threshold values, whereby those elemen- 
tary event values are taken into account which exceed or fall short of the 
threshold values. 

When the report request service block has performed the analysis, 

15 it determines which are counter service blocks CSB, the elementary event 
values of which are needed in the report, step 62. The contents of the start- 
up message contain at least: a) the required elementary events, b) the time- 
table data relating to the reading of events, c) threshold values and d) data 
showing to which report request service block the reply is to be sent. Since 

20 there may be many start-up messages, they are assembled to forni a mes- 
sage in accordance with Figure 4. Thereupon the start-up messages are 
sent to those CSBs which the matter concerns, step 63. The concemed 
counter service blocks receive the start-up messages and interpret from 
these on what conditions the counters are to be read, steps 64 and 65. 

25 Thereafter they read the counters in accordance with the given In- 

structions, step 66, form the reply messages, step 67, and send them to the 
report request service block which requested the counter data, step 68. The 
report request service block receives the reply messages, step 69. and uses 
the data contained in the messages for forming reports, step 610. 

30 

Second embodiment of the invention 

it is a drawback of the static embodiment described above that the 
counter service blocks are defined in advance and there may be quite a lot of 
them, especially if it is desired that each counter has a controller of its own. 
35 Although the counter sen/ice blocks are very simple and their structure is 
very reliable, they may nevertheless produce an unnecessary load on the 
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system. This is avoided in the arrangement according to the second em- 
bodiment of the invention, where as many counter service blocl<s are created 
as are required at each time. This arrangement is called a dynamic embodi- 
ment. 

5 Figure 7 illustrates the dynamic embodiment, it differs from the 

embodiment according to Figure 5 only in that Feature l\/lanagement Block 
FMB 71 is added to the system. Its duty is 

a) to manage simple counter service blocks (counter conti-ollers), 

b) to store and relay information to the report request service 
10 blocks on what counters the system can provide. 

c) function as an interface between the report request service 
blocks and the hardware counters. 

When some report request service block needs a set of counter 
data in order to form a report, it sends a list of counters to the management 
16 block. The list may be a similar start-up message as was described in con- 
nection with Figures 2 and 4. The message may thus contain various timeta- 
bles and conditions. The management block receives the list, checks what 
counters are required and whether the counter already has a counter service 
block of its own. If it does not have one, it creates for each counter a con- 
20 troller of its own, or it may connect several counters to one controller. 

Thereafter the operation goes on in the same way as in the case 
of the static embodiment, because the counter service blocks function ex- 
actly In the same way in each embodiment. 

The arrangement In accordance with the second embodiment is 
25 flexible. If the report request service block demands reports of a new kind or 
counter data arranged in another way than was designed originally, it will 
suffice just to send a new start-up message to the feature management 
block FMB. The feature management block creates a nevv counter service 
block together with the proper counters connected to it, whereby the created 
30 new counter service block will carry out the request. 

The management programme may remove a new counter service 
block as easily as it created it, if it is no longer required. 

Figure 8 shows a block diagram of the operational steps of the 
second embodiment. In many respects the steps are the same as in the 
35 diagram shown in Figure 6, and the same reference numbers are used in 
these respects. The report request service block forms a start-up request In 
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the normal manner, which request contains the counter Identifiers and condi- 
tions needed for the report, step 63. The start-up request Is sent to feature 
management blocl< FMB, which receives the start-up request, step 71, and 
performs an analysis of the request, step 72. In the analysis it Identifies the 
6 counters needed when fulfilling the request, step 72. First it checks if control- 
ling counter service blocks already exist for the required counters. If these 
already exist, it gives them the start-up messages proper, whose form was 
described above in connection with Figures 2 and 4. Thereupon the counter 
sen/ice blocks function in accordance with the conditions given in the start- 

10 up messages. Thus, feature management block FMB is a kind of host proc- 
ess for the counter service blocks. 

Should the analysis indicate that a counter service block is lacking 
for some of the counters or even for all counters named in the start-up mes- 
sage sent by the report request service block, it is the duty of the feature 

15 management block to fomri the lacking counter service blocks. Thus it forms 
the required counter service blocks, step 73. and then gives the start-up 
messages proper to them in which the conditions are given for reading the 
countei^. From this step fonfl/ard, the function continues as in the case of the 
static embodiment, that is, the counter sen/ice blocks fomi reply messages, 

20 step 67. and send them to the report request service block, step 68. The 
process receives the messages sent by the counter service blocks and uses 
the information they contain for forming reports, step 610. 

Advantages of the dynamic solution according to the second em- 
bodiment are, first, that only the necessary counter service blocks exist, 

25 there are no units using extra resources. Secondly, the counters themselves 
and also the counter service blocks may be covered from the party needing 
the sen/ice. Hardware dependent parts of the an-angement affect parts of the 
upper level as little as possible and thus the hardware can be changed with- 
out necessitating any changes e.g. in the report request service blocks. 

30 Thirdly, should the report request service blocks need reports of a new kind 
or counter data arranged in another way than originally designed, it is easy 
to make such changes. This Is so because with the aid of the feature man- 
agement block FMB it is easy to create a new counter service block, which 
will fulfil the request. 
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It is an advantage of the anrangement according to the invention 
compared with state-of-the-art arrangements that of elementary events only 
those are transmitted which are needed at the moment. Even if the number 
of elementary events and the number of counters may be very high, it is 

5 easy to select for reading only those which are needed. The selection of 
chosen events can be easily implemented by giving a suitable value in the 
fields of the start-up messages produced by the report request service block. 

The counter service blocks are small programme bits performing a 
function depending on the parameters supplied to them. In this sense they 

10 resemble the Service Independent Building Blocks SIB which are used in 
intelligent network architecture. 
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Claims 

1. A system for extracting desired information from information in- 
coming from a plurality of different Information sources, character- 
ized in that it includes: 

a fiiist main block (21) which includes at least one service process 
and which forms a start-up message (23), which names both those informa- 
tion sources which supply Information which the service process wishes to 
extract from Incoming infomiatlon. and conditions whose fulfilment means 
that each piece of information must be stated to the service process, 

a second main block (22) which includes several control proc- 
esses and wherein the control processes are connected to receive Informa- 
tion incoming from Information sources, and wherein the control process 

in response to the start-up message reads the information am'ving 
from the named information sources in accordance with the given conditions, 

forms a reply message (31) containing the information of the in- 
formation sources stated in the start-up message, and 

sends the reply message to the service process. 

2. System as defined in claim 1, characterized in that to 
each control process (24, 25) is connected at least one Information source 
and that the conditions given in the start-up message concern all these In- 
formation sources. 

3. System as defined In claim 2, characterized in that the 
control process and the information sources connected to It form a prede- 
termined permanent entity. 

4. System as defined in claim 2, characterized in that it 
also includes a feature management block, which 

in a service request arriving from the service process receives in- 
fonnation on which is the information in the information sources which the 
service process wishes to extract from the anriving Infonnation, and 

forms and sends a start-up message to the control process. 

5. System as defined in claim 4, characterized in that the 
management block creates the control process and connects the required 
information sources to it. 
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6. System as defined in claim 5. cliaracterized in that tlie 
control process is temporary and it is discontinued after tlie reply messages 
have been sent. 

7. System as defined in claim 4, characterized in that the 
5 management process maintains Information on what information sources the 

system provides and it relays this information to the sen/ice process. 

8. System as defined in claim 1, characterized in that the 
service process sends the information arriving in the reply message for fur- 
ther processing. 

10 9. System as defined in claim 1, characterized in that the 

condition in the start-up message is a threshold value, whereby any informa- 
tion exceeding or falling short of it must be stated. 

1 0. System as defined in claim 1, characterized in that the 
condition in the start-up message is a timetable . which must be fpllowed 

15 when giving the information. 

11. System as defined in claim 1, characterized In that the 
start-up message contains the identifier of that service process to which the 
reply message must be sent. 

12. A telephone exchange including many units producing ele- 
20 mentary events, such as counters and measuring units, and wherein ele- 
mentary event infonnation Is collected for further processing, c h a r - 
a c t e r i z e d in that it includes: 

at least one seryice process collecting elementary event infor- 
mation which fomns a start-up message naming both those units producing 
25 elementary events whose produced information the service process requires 
and the conditions whose fulfilment means that each piece of information 
must be stated to the service process, 

several controllers, each of which is connected to at least one unit 
producing elementary events to receive the information which it produces, 
30 and which 

In response to the start-up message addressed to themselves will 
read the named elementary event infonnation in accordance with the given 
conditions, 

form a reply message containing the information on the elemen- 
35 tary event ways stated in the start-up message, and 

send the reply message to the service process. 
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13. Telephone exchange as defined In claim 12, c h a r a c t e r - 
i z e d in that to each controller is connected at least one unit producing 
elementary events and that the conditions given in the start-up message 
concern all these elementary events. 

14. Telephone exchange as defined in claim 12, character- 
ize d in that the controller and the connected units producing elementary 
events form a predetermined permanent entity. 

15. Telephone exchange as defined In claim 12. character- 
ize d in that it also includes a feature management block which 

in the service request arriving from the service process receives 
information on which elementary event information the service process re- 
quires and 

forms and sends the start-up messages to the controllers. 

16. Telephone exchange as defined in claim 15, character- 
ize d in that the feature management block creates the controller and con- 
nects the elementary event producing units to it. 

17. Telephone exchange as defined in claim 16, character- 
ize d in that the controller is temporary and it will be discontinued when the 
reply messages have been sent. 

18. Telephone exchange as defined in claim 15, character- 
ize d in that the management process maintains information on what ele- 
mentary events the system provides and rt relays this information to the 
service processes. 

19. Telephone exchange as defined In claim 12, c h a r a c t e r - 
I z e d in that the start-up message includes the identifier of the service 
process to which the reply message must be sent. 
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